Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

scripts/run-playwright.mjs (1)

71-77: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider consolidating duplicated findFreePort logic.

findFreePort here is nearly identical to the one in scripts/dev-free-port.mjs (differing only in the loop bound: projectPortEnd vs maxPort). Now that both share isReservedDevPort/stableProjectPort from local-server-utils.mjs, extracting a shared findFreePort(startPort, endPort) helper into that module would remove the remaining duplication and prevent future drift (e.g., if the reserved-port skip logic needs to change again).

♻️ Suggested shared helper (illustrative)

// src/lib/local-server-utils.mjs
export async function findFreePort(startPort, endPort, canListen) {
  for (let port = startPort; port <= endPort; port += 1) {
    if (isReservedDevPort(port)) continue;
    if (await canListen(port)) return port;
  }
  throw new Error(`No free port found from ${startPort} to ${endPort}.`);
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/run-playwright.mjs` around lines 71 - 77, Consolidate the duplicated
findFreePort logic from scripts/run-playwright.mjs and scripts/dev-free-port.mjs
into a shared findFreePort(startPort, endPort, canListen) helper in
local-server-utils.mjs. Preserve reserved-port skipping and inclusive bounds,
update both callers to pass their respective end ports and canListen functions,
and retain clear no-free-port error handling.

src/lib/differential-detail.ts (1)

138-157: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Investigations list is unbounded in the clipboard register, unlike actions.

actions is capped to slice(0, 6) (Line 145) but investigations (Lines 150-154) has no cap. A record with many investigations produces an unbounded "Copy after review" clipboard payload, inconsistent with the actions cap.

💡 Proposed fix

-  const investigations = record.investigations.map(cleanDifferentialItem).filter(Boolean);
+  const investigations = record.investigations.map(cleanDifferentialItem).filter(Boolean).slice(0, 6);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/differential-detail.ts` around lines 138 - 157, Cap the
investigations included by formatDifferentialCopyText to the same six-item limit
as immediate actions. Update the investigations mapping/filtering chain to apply
slice(0, 6) before rendering the “Investigations” section.

src/lib/differentials.ts (1)

124-159: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Redundant snapshot load and uncached catalog Set inside getDifferentialDetailContext.

Two inefficiencies compound in this function, called once per diagnosis page render/build:

• Line 125 rebuilds catalogSlugs as a fresh Set on every call, unlike the memoized diagnosisTitleSlugMap() pattern used just above it.
• Line 140 calls differentialPresentations() (which internally loads the snapshot via catalog()), then Line 144 calls loadDifferentialSnapshot() again directly — reloading/reparsing the same snapshot twice per call. Since catalog() is literally return loadDifferentialSnapshot();, this second call is redundant and can reuse the same snapshot object.

Across many statically generated diagnosis pages (generateStaticParams), this adds up to unnecessary repeated I/O/parsing during build.

♻️ Proposed fix

   const presentation =
-    differentialPresentations().find((workflow) =>
+    catalog().presentations.find((workflow) =>
       workflow.candidates.some((candidate) => candidate.slug === record.slug),
     ) ?? null;
 
-  const snapshot = loadDifferentialSnapshot();
+  const snapshot = catalog();
   const governance = deriveGovernanceFromSnapshot(snapshot);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/differentials.ts` around lines 124 - 159, Optimize
getDifferentialDetailContext by reusing memoized data: introduce a module-level
or memoized catalog slug Set instead of rebuilding catalogSlugs on every call,
and load the differential snapshot once before deriving presentation and
governance. Reuse that snapshot for differentialPresentations or add an
equivalent snapshot-aware path so the function does not trigger the
catalog-backed load and then call loadDifferentialSnapshot again.

src/components/differentials/differential-detail-page.tsx (2)

447-501: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Duplicated related-node row markup between RelatedDiagnoses and ComparePanel.

Both components repeat the same title/note + likelihood-badge + conditional Link-vs-div wrapper structure (lines 456-497 and 598-630) with only cosmetic class differences. Extracting a small shared RelatedNodeRow helper (taking node, known, and a variant for styling) would remove ~50 lines of near-identical JSX and keep future tone/badge changes in one place.

Also applies to: 597-631

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/differentials/differential-detail-page.tsx` around lines 447 -
501, Extract the duplicated related-node row JSX from RelatedDiagnoses and
ComparePanel into a shared RelatedNodeRow helper that accepts the node,
known-state, and styling variant. Preserve the existing title, note, likelihood
badge, conditional Link-versus-div behavior, test id, href, and cosmetic class
differences, then replace both inline implementations with the helper.

---

812-844: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

aria-controls on inactive tabs points to an unmounted panel id.

Every tab button sets aria-controls={differential-panel-${tab.id}}, but only one <div role="tabpanel" id={differential-panel-${activeTab}}> is ever rendered (line 1002). For the four inactive tabs, aria-controls references an id that doesn't exist in the DOM, which is a real ARIA authoring-practices violation for tabs (each tab's aria-controls should resolve to an existing panel element).

🔧 Proposed fix

-            aria-controls={`differential-panel-${tab.id}`}
+            aria-controls={isActive ? `differential-panel-${tab.id}` : undefined}

Also applies to: 853-865

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/differentials/differential-detail-page.tsx` around lines 812 -
844, Fix the tab/panel ARIA relationship in the Tabs component and its tab
button rendering: ensure every tab’s aria-controls references an existing panel
element, either by rendering panels for all tabs or by removing aria-controls
from inactive tabs and retaining it only for the active tab. Keep the panel IDs
consistent with the tab IDs and update related aria attributes as needed.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".